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Logic programs for MIP generation 

Finding the most probable (MAP) model 
in SRL frameworks such as Markov logic 
(Richardson and D omingos 2006) l and Problog 
(IFierens et al. 2013t can, m principle, be solved by 
encoding the problem as a ‘grounded-out’ mixed 
integer program (MIP). However, useful first-order 
structure disappears in this process motivating the de¬ 
velopment of first-order MIP approaches. Here we 
present mfoilp, one such approach. Since the syntax 
and semantics of mfoilp is essentially the same as 
existing approaches ([Gordon, Hong, and Dudrk 2009 


|Kersting, Mladenov, and Tbkmakov 20l4| we focus here 
mainly on implementation and algorithmic issues. We start 
with the (conceptually) simple problem of using a logic 
program to generate a MIP instance before considering 
more ambitious exploitation of first-order representations. 

A MIP instance consists of variable and linear con¬ 
straint declarations. It is straightforward to effect these 
declarations as a logic program. In the case of mfoilp 
this logic program is written in the Mercury language 
(]Somogyi, Henderson, and Conway 1996) as follows. 

Mercury programs are made up of modules. Mercury 
modules are composed of an interface and an implementa¬ 
tion, where everything in a modules’s implementation is hid¬ 
den from other modules. Fet the Mercury module defining a 
MIP instance be called prob . m. Its interface is as follows: 

import_module mfoilp. 


type atom. 


- pred variable(atom::out) is multi. 

- pred constraint(lincons::out) is nondet. 

- func objective(atom) = float. 

- func lb(atom) = float. 

- func ub(atom) = float. 

- func vartype(atom) = vartype. 


Terms of type atom correspond to MIP variables. This 
type is an abstract type, its definition, which the user has 
to provide in the module implementation, is hidden from 
other modules. The 4 functions objective, lb, ub and 
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vartype have to provide, respectively, the objective co¬ 
efficient, the lower bound, upper bound and MIP variable 
type (integer- or real-valued) for each atom. The predicate 
variable /1 is used to generate all MIP variables by Mer¬ 
cury’s equivalent of findall. For example, suppose the 
type atom were defined as follows 

type protein -> pl;p2. 

type location_id -> 11;12. 

type atom -> 

location(protein,location_id) 

; interaction(protein,protein) . 

then we could have: 

variable(location(Protein,Location_id)) :- 

protein (Protein), location_id(Location_id) . 
variable(interaction(Proteinl,Protein2)) :- 

protein(Proteinl), protein(Protein2). 

where protein/1 and location_id/1 generate pro¬ 
teins and location Jds, respectively. 

Constraints are similarly straightforward. The lincons 
(linear constraint) type is defined in the mfoilp module as 
follows: 

import_module prob. 

type Iterm -> (float * atom). 

type lexp == list(Iterm). 

type lb-> finite (float) ; neginf. 

type ub-> finite (float) ; posinf. 

type lincons-> lincons(lb,lexp,ub) . 

So a linear term is just an atom together with its coeffi¬ 
cient, and a linear constraint is just a list of such terms (rep¬ 
resenting their sum) bounded by a lower and upper bound. 

Absent bounds are represented by constants representing ei¬ 
ther positive or negative infinity. Note that the prob module 
must be imported so that the (abstract) type atom is avail¬ 
able. The predicate constraint/1 should be defined so 
that all required constraints can be generated by findall. 
FiglUprovides an example. 

mfoilp 

mfoilp consists of a C program (main . c), a Mercury pro¬ 
gram (mf oilp .m) and a Makefile. C code in main . c asks 
for (and receives) the list of variables and list of constraints 
from mfoilp.m which in turn gets them from prob.m 



















constraint(lincons(finite (1.0), 

[1.0 * location(PI,LI), 

1.0 * interaction(PI,P2)],posinf)) 
protein(Pl), protein(P2), not PI = P2, 
location_id(LI). 

Figure 1: A first-order linear constraint 


pred price(duallpsol::in, 

variable::out) is nondet. 

price(DualLPSol,Var) 
variable(Var), 

reduced_cost(DualLPSol,Var,RedCost) , 
RedCost < 0. 


which defines the problem instance. It then calls the SCIP 
(Achterberg 2009 1 system to create and solve the MIP in¬ 
stance. The components of mfoilp are connected as follows. 
SCIP - main.c - mfoilp.m - prob.m 

Solving is invoked with make solution. This causes 
pr ob. m to be compiled (and linked) to generate a problem- 
specific executable. This executable is then run to solve the 
MIP. 


Branch-price-and-cut 

A logic program is obviously a very flexible way of defining 
a MIP instance. However, the approach just outlined will fail 
with large numbers of variables and/or constraints since all 
have to be squeezed into memory prior to any solving. An al¬ 
ternative is to implement a branch-price-and-cut (BPC) ap¬ 
proach to solving the MIP. Assume wlog that we are min¬ 
imising. In BPC some initial variables and constraints are 
created as normal and the LP solution x* computed, giving 
a lower bound on an optimal solution. Next a cutting plane 
algorithm looks for valid inequalities which x* violates. If 
any are found they are added and a new LP solution with 
a tighter (higher) lower bound can be computed. In addi¬ 
tion a pricer algorithm is run to look for variables which, if 
created, would produce a looser (lower) lower bound. Such 
variables are those with negative reduced cost, a quantity 
which can be computed from the variable’s objective coef¬ 
ficient and the solution to the dual LP. If the pricer can es¬ 
tablish that there are no variables with reduced cost then we 
have a global lower bound without creating all possible vari¬ 
ables. If we reach such a point and all integer variables hap¬ 
pen to have integer values in the LP solution then the MIP 
is solved. Otherwise BPC branches on a variable to create 
sub-problems and applies BPC recursively until an guaran¬ 
teed optimal solution is found. 

It is easy to augment mfoilp with a predicate implement¬ 
ing a cutting plane algorithm; 

pred cut(Ipsol::in, 

lincons::out) is nondet. 

cut(LPSol,CP) 
constraint (CP), 
activity(LPSol,CP,Activity), 
violates_bounds(Activity,CP). 

Mercury’s default execution algorithm processes goals left 
to right, so in this approach (1) a potential cutting plane is 
generated, (2) the value of its linear expression for the given 
LP solution (its activity) is computed and (3) the predicate 
succeeds if this value exceeds one of the constraint’s bounds. 
Similarly, a pricer can be implemented as follows; 


Such an approach avoids the need to generate all variables 
and constraints ahead-of-time, since only those which affect 
the LP bound are generated. And we can leave SCIP to take 
care of branching. However, both cut/2 andprice/2 are 
hopelessly inefficient—being pure generate-and-test. 

An attractive alternative is to (1) take advantage of any 
special structure in variable/constraint definitions and (2) ef¬ 
fect a source-to-source transformation similar to unfolding 
to produce more efficient code. For example, all the vari¬ 
ables in the constraint in Fig [T] have positive coefficients, 
which can be exploited to automatically produce the follow¬ 
ing specialised cut/2 clause; 

cut(LPSol,CP) 

protein (PI), location_id(LI), 
get_val(LPSol,location(PI,LI),Vall), 
Vail < 1, 

interaction(PI, P2) , not PI = P2, 
get_val(LPSol,interaction(P1,P2),Val2), 
Vail + Val2 < 1. 

CP = lincons ( ... ) . %lit abbreviated 

mfoilp is currently being extended in this direction with 
a SCIP constraint handler and SCIP pricer which will call 
Mercury code to generate the required constraints and vari¬ 
ables. (An earlier version of mfoilp called f oz does imple¬ 
ment cutting planes but does not use Mercury and has a naive 
cutting plane algorithm.) 


Related work 


In mfoilp there is a bijection between MIP vari¬ 
ables and first-order terms. However, these terms can 
be usefully thought of as atomic formula (and so 
the predicates become meta-predicates) in which case 
the syntax and semantics of mfoilp are basically the 
same as first-order programming (FOP) introduced by 
(jGordon, Hong, and Dudfk 2009|) where “A MILP variable 
corresponds to a FOP ground atom”. Further work is needed 
to see how the approach to inference in FOP presented 
in ( [Zawadzki, Gordon, and Platzer 2011] ) relates to the BPC 
method advocated here. 

If all variables are continuous then an mfoilp in¬ 
stance is equivalent to a relational linear program 
(RLP) (Kersting, Mladenov, and Tokmakov 2014) which is 
a “declarative LP template defining the objective and the 
constraints through the logical concepts of objects, relations 
and quantified variables.” It follows that, even with integer 
variables, mfoilp should take advantage of the ‘lifted’ LP 
solving technique of Kersting et al since solving linear re¬ 
laxations plays such a key role in MIP solving. 
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